Sortie de Debian 11 « Bullseye »

Posté par  . Édité par Ysabeau 🧶, Pierre Jarillon, Benoît Sibaud et claudex. Modéré par Pierre Jarillon. Licence CC By‑SA.
92
18
août
2021
Debian

La distribution Debian 11 « Bullseye » a été publiée le 14 août 2021. Cette dépêche est largement tirée de l'annonce du projet.

Après deux ans, un mois et neuf jours de développement, le projet Debian est fier d’annoncer sa nouvelle version stable n° 11 (nom de code « Bullseye ») qui sera suivie pendant les cinq prochaines années grâce à l’effort combiné de l'équipe de sécurité de Debian (EN) et de l'équipe de gestion à long terme de Debian (EN).

Cette version contient plus de 11 294 nouveaux paquets pour un total de 59 551 paquets, avec un nombre significatif de paquets (9 519) marqués comme « obsolètes » et supprimés. 42 821 paquets ont été mis à jour et 5 434 demeurent inchangés.

Sommaire

Les nouveautés

Debian 11 « Bullseye » inclut maintenant notamment les environnements de bureau suivants :

Gnome 3.38 ;
KDE Plasma 5.20 ;
LXDE 11 ;
LXQt 0.16 ;
MATE 1.24 ;
Xfce 4.16.

« Bullseye » est la première version de Debian à fournir un noyau Linux avec la prise en charge du système de fichiers exFAT et qui l’utilise par défaut pour monter les systèmes de fichiers exFAT. Par conséquent, il n’est plus nécessaire d’utiliser l’implémentation du système de fichiers dans l’espace utilisateur fournie par paquet exfat-fuse. Les outils pour créer et vérifier un système de fichiers exFAT sont fournis par le paquet exfatprogs.

La plupart des imprimantes récentes sont capables d’utiliser l’impression et la numérisation sans pilote donc sans avoir besoin des pilotes spécifiques du fabricant (souvent non libres). « Bullseye » introduit un nouveau paquet, ipp-usb, qui utilise le protocole IPP-over-USB indépendant du fabricant et pris en charge par beaucoup d’imprimantes récentes. Cela permet à un périphérique USB d’être vu comme un périphérique réseau. Le dorsal officiel SANE sans pilote est fourni par sane-escl du paquet libsane1 qui utilise le protocole eSCL.

Dans « Bullseye », systemd active par défaut sa fonctionnalité de journal persistant avec un repli implicite sur un stockage volatil. Cela permet aux utilisateurs qui ne dépendent pas d’une fonctionnalité particulière de désinstaller les démons de journalisation traditionnels et de passer à l’utilisation exclusive du journal de systemd.

L’équipe Debian Med a pris part à la lutte contre la COVID-19 en empaquetant des paquets pour la recherche sur le virus au niveau de son séquençage et pour combattre la pandémie avec les outils utilisés en épidémiologie. Ce travail va continuer en mettant l’accent sur les outils d’apprentissage automatique dans ces deux domaines. Le travail de l’équipe sur l’assurance qualité et l’intégration continue est essentiel sur le plan de la cohérence et de la reproductibilité des résultats indispensable dans le domaine scientifique. Le mélange Debian Med possède une série d’applications cruciales pour leurs performances qui bénéficient maintenant de SIMD Everywhere. Pour installer les paquets entretenus par l’équipe Debian Med, il suffit d’installer les métapaquets nommés med-* qui sont en version 3.6.x.

Le chinois, le japonais, le coréen et d’autres langues bénéficient de la nouvelle méthode de saisie Fcitx 5 qui succède à la méthode Fcitx 4, populaire dans « Buster ». Cette nouvelle version prend bien mieux en charge les extensions de Wayland (le gestionnaire d’affichage par défaut).

Debian 11 « Bullseye » inclut de nombreux paquets logiciels mis à jour (plus de 72 % des paquets de la distribution précédente), par exemple :

Apache 2.4.48
Serveur DNS BIND 9.16
Calligra 3.2
Cryptsetup 2.3
Emacs 27.1
GIMP 2.10.22
Collection de compilateurs GNU 10.2
GnuPG 2.2.20
Inkscape 1.0.2
LibreOffice 7.0
Noyaux Linux série 5.10
MariaDB 10.5
OpenSSH 8.4p1
Perl 5.32
PHP7.4
PostgreSQL 13
Python 3, 3.9.1
Rustc 1.48
Samba 4.13
Vim 8.2
plus de 59 000 autres paquets prêts à l’emploi, construits à partir de plus de 30 000 paquets source.

Avec cette large sélection de paquets, ainsi que sa traditionnelle gestion de nombreuses architectures, Debian, une fois de plus, confirme son but d’être le « système d’exploitation universel ». Elle est appropriée pour bien des cas différents d’utilisation : des systèmes de bureau aux mini portables, des serveurs de développement aux systèmes pour grappe, ainsi que des serveurs de bases de données aux serveurs web ou de stockage. En même temps, des efforts supplémentaires d’assurance qualité tels que des tests automatiques d’installation et de mise à niveau pour tous les paquets de l’archive Debian garantissent que « Bullseye » répond aux fortes attentes de nos utilisateurs lors d’une publication stable de Debian.

Un total de neuf architectures sont gérées : PC 64 bits/Intel EM64T/x86-64 (amd64), PC 32 bits/Intel IA-32 (i386), PowerPC 64 bits Motorola/IBM petit-boutiste (ppc64el), IBM S/390 64 bits (s390x), pour ARM, armel et armhf pour les anciens et nouveaux matériels 32 bits plus arm64 pour l’architecture 64 bits « AArch64", et pour MIPS, mipsel (petit-boutiste) pour les matériels 32 bits et mips64el pour le matériel 64 bits petit-boutiste.

Vous voulez l’essayer ?

Si vous voulez simplement essayer Debian 11 « Bullseye » sans l’installer, vous pouvez utiliser une des images autonomes « live » qui chargent et exécutent le système d’exploitation complet, dans un mode en lecture seule, dans la mémoire de votre ordinateur.

Ces images autonomes sont fournies pour les architectures amd64 et i386 et sont disponibles pour des installations à l’aide de DVD, clés USB ou d’amorçage par le réseau. Les utilisateurs peuvent choisir entre plusieurs environnements de bureau : GNOME, KDE Plasma, LXDE, LXQt, MATE et Xfce. Debian « Bullseye » autonome fournit une image autonome standard, ainsi, il est possible d’essayer un système Debian de base sans interface utilisateur graphique.

Si le système d’exploitation vous plaît, vous avez la possibilité de l’installer sur le disque dur de votre machine à partir de l’image autonome. Celle-ci comprend l’installeur indépendant Calamares ainsi que l’installeur Debian standard. Davantage d’informations sont disponibles dans les notes de publication et sur la page de la section des images d’installation autonomes du site de Debian.

Si vous souhaitez installer Debian 11 « Bullseye » directement sur le disque dur de votre ordinateur, vous pouvez choisir parmi les nombreux supports d’installation tels que les disques Blu-ray, CD et DVD et les clefs USB, ainsi que par une connexion réseau. Plusieurs environnements de bureau — Cinnamon, GNOME, KDE Plasma Desktop et Applications, LXDE, LXQt, MATE et Xfce — peuvent être installés grâce à ces images. De plus, des disques « multi-architecture » sont disponibles et permettent l’installation à partir d’un choix entre plusieurs architectures à partir d’un seul disque. Vous pouvez aussi toujours créer un média d’installation amorçable sur clef USB (voir le manuel d’installation pour plus de détails).

Au sein de l’installateur Debian, beaucoup de développement a été réalisé aboutissant à une amélioration de la prise en charge du matériel et à d’autres nouvelles fonctionnalités.

Dans certains cas, une installation réussie peut encore présenter des problèmes d’affichage lors du redémarrage dans le système installé ; pour ces cas, il y a quelques solutions (EN) qui pourraient aider à se connecter quand même. Il existe aussi une procédure basée sur isenkram (EN) qui permet aux utilisateurs de détecter et de corriger l’absence de microcode dans leur système de façon automatique. Bien sûr, il faut peser le pour et le contre de l’utilisation de cet outil dans la mesure où il est probable qu’il nécessitera l’installation de paquets non libres.

En complément à cela, les images d’installation non libres qui incluent les paquets de microcode (EN) ont été améliorées pour qu’elles puissent anticiper le besoin de microcode sur la machine installée (par exemple, pour les cartes graphiques AMD ou Nvidia ou pour les dernières générations de matériel audio d’Intel).

Pour les utilisateurs et utilisatrices de nuage, Debian propose la prise en charge directe de beaucoup des plateformes de nuage bien connues. Les images officielles de Debian sont faciles à sélectionner sur chaque offre d’image. Debian publie également des images OpenStack (EN) toutes prêtes pour les architectures amd64 et arm64, prêtes à être téléchargées et utilisées dans des configurations de nuage locales.

Debian peut maintenant être installée en 76 langues, dont la plupart sont disponibles avec des interfaces utilisateur en mode texte et graphique.

Les images d’installation peuvent être téléchargées dès à présent au moyen de bittorrent (le moyen recommandé), jigdo ou HTTP ; consultez la page Debian sur CD pour plus d’informations. « Bullseye » sera également bientôt disponible sur DVD, CD et disques Blu-ray physiques chez de nombreux distributeurs.

Mise à niveau de Debian

La mise à niveau vers Debian 11 à partir de la version précédente, Debian 10 (nom de code « Buster ») est gérée automatiquement par l’outil de gestion de paquets APT pour la plupart des configurations.

Pour « Bullseye », la suite de sécurité s’appelle maintenant bullseye-security et les utilisateurs devraient adapter leur fichier de liste de sources d’APT en conséquence lors de la mise à niveau. Si votre configuration d’APT comprend également l’épinglage ou la ligne APT::Default-Release, il est vraisemblable qu’elle nécessite aussi des adaptations. Consultez la section Changement de l’organisation de l’archive security des notes de publication pour plus de détails.

Si vous effectuez une mise à niveau à distance, n’oubliez pas de consulter la section Impossible d’établir de nouvelles connexions SSH durant la mise à niveau.

Comme toujours, les systèmes Debian peuvent être mis à niveau sans douleur, sur place et sans période d’indisponibilité forcée, mais il est fortement recommandé de lire les notes de publication ainsi que le manuel d’installation pour d’éventuels problèmes et pour des instructions détaillées sur l’installation et la mise à niveau. Les notes de publications seront améliorées et traduites dans les semaines suivant la publication.

À propos de Debian

Debian est un système d’exploitation libre, développé par plusieurs milliers de volontaires provenant du monde entier qui collaborent à l’aide d’Internet. Les points forts du projet sont l’implication basée sur le volontariat, l’engagement dans le contrat social de Debian et le logiciel libre, ainsi que son attachement à fournir le meilleur système d’exploitation possible. Cette nouvelle version représente une nouvelle étape importante dans ce sens.

Aller plus loin

  • # C'est qui, Bullseye ?

    Posté par  . Évalué à 10. Dernière modification le 18 août 2021 à 23:42.

    Pour ceux qui, comme moi, se demandent quel personnage de Toy Story est Bullseye : c'est le cheval apparu dans Toy Story 2, et dont le nom français est Pile-Poil.

  • # upgrade process

    Posté par  (site web personnel) . Évalué à -2.

    A quand un bouton ou commande de mise a jour de version pour mme michu qui ne veut pas passer du temps à savoir comment editer le source list avec VI dans un terminal?

    Sinon, blague a part. Le "apt full-upgrade" direct ne marche pas. Il faut d'abord faire un upgrade puis le full-upgrade.

    • [^] # Re: upgrade process

      Posté par  . Évalué à 3.

      Sinon, blague a part. Le "apt full-upgrade" direct ne marche pas. Il faut d'abord faire un upgrade puis le full-upgrade.

      J’ai fait deux mises à niveau avec apt full-upgrade hier. Qu’est-ce qui n’a pas fonctionné pour toi ?

    • [^] # Re: upgrade process

      Posté par  . Évalué à 6.

      A quand un bouton ou commande de mise a jour de version pour mme michu qui ne veut pas passer du temps à savoir comment editer le source list avec VI dans un terminal?

      Quelque chose comme ?

      apt update && apt upgrade --without-new-pkgs && apt full-upgrade

      Si tu as des dépôts tiers à virer c'est probablement que tu as su les ajouter ;)

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: upgrade process

        Posté par  . Évalué à 10.

        Je pense qu’il faut plutôt proposer quelque chose de "moderne" :

        curl https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.html | sudo bash -
        
        • [^] # Re: upgrade process

          Posté par  . Évalué à 7. Dernière modification le 19 août 2021 à 15:07.

          Ouais, mais le copier coller d'une longue commande comme ça c'est dangereux, je propose plutôt d'utiliser npx, c'est plus simple que Curl dont on comprend rien aux paramètres, en plus piper vers bash c'est mal, donc :

          sudo npx update-to-debian-bullseye
          

          Je suggère que le script affiche le nombre de paquets vulnérables, et une soupe d'émojis pour indiquer la progression de la mise à jour et sa réussite, du style : « All done! ✨ 🍰 ✨ »

  • # un point intéressant pour la prochaine version (la 12 aka bookworm)

    Posté par  . Évalué à 6. Dernière modification le 19 août 2021 à 09:57.

    la doc de maj de bullseye précise que l'arborescence de base va changer sur la version 12

    https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html#deprecated-components

    Les raisons historiques de l’organisation du système de fichiers avec des répertoires /bin, /sbin et /lib séparés de leurs équivalents dans /usr ne s’appliquent plus aujourd’hui ; veuillez consulter le résumé de Freedesktop.org. Debian Bullseye sera la dernière publication de Debian prenant en charge cette organisation non fusionnée ; pour les systèmes utilisant une organisation à l’ancienne et ayant été mis à niveau sans faire de réinstallation, le paquet usrmerge permet de faire la conversion.

    bookworm c'est une luciole/veilleuse verte et joufflue

    • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

      Posté par  . Évalué à 3.

      bon le lien vers freedesktop permet de voir que c'est pas vraiment neuf tout ça
      https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

      • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

        Posté par  . Évalué à 6.

        Ce n’est pas neuf dans Debian non plus, puisque c’est l’arborescence utilisée par défaut sur les nouvelles installations depuis Buster (cf. les notes de publication de Debian 10).

        Ce qui va changer avec Bookworm, c’est que tous les systèmes passeront sur cette arborescence fusionnée.
        Dans les archives de la liste debian-devel, on peut voir que tout le monde n’est pas ravi par cette transition (fil 'merged /usr considered harmful'), donc ça arrive peut-être même trop vite !

      • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

        Posté par  . Évalué à 6.

        Ce qui est dommage, c'est que c'est pas l'organisation la plus en vue pour parler de ça.
        C'est plus du ressort de FHS. Note je ne dis pas que le changement n'a pas d'intérêt, mais que ça serait intéressant de pousser un FHS 4 pour porter ces changements et élargir la discussion avec les amis bsdistes par exemple.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  . Évalué à 3.

          Du coup, il y a plus de chance d'avoir les bsdiste avec freedesktop qui se veut généraliste qu'avec FHS qui est géré par le Linux Standard Base workgroup de la Linux Foundation.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

            Posté par  . Évalué à 4.

            J'ai vraiment un doute. Déjà en terme de groupe de travail l'un est dans la LSB, mais l'autre est dans systemd. Mais la spécification freedesktop ne semble pas être un travail de standardisation avec groupe de travail, mais une documentation pour entérinée le travail fait sur fedora. Les liens entre freedesktop et RedHat forts au détriment des autres acteurs de linux (Gnome/KDE par exemple) est assez habituel et semble encore être le cas ici (indépendamment de la qualité qui en sort).

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

        Posté par  (site web personnel) . Évalué à 2.

        Et peut être qu'un jour on renommera usr et etc en quelque-chose de parlant !

        /Programs et /Configs ?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  (site web personnel) . Évalué à 5.

          Tu veux dire https://www.gobolinux.org/ ?

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

            Posté par  (site web personnel) . Évalué à 9.

            Oui mais avec plus de 3 utilisateurs !

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

              Posté par  (site web personnel) . Évalué à 5.

              Bah alors autant renommer en "Program Files" et ProgramData …

              … on pourrait même envisager un mappage de Program Files vers Programmes quand le système est localisé Fr_fr histoire de "simplifier" les choses …

              Toute ressemblance avec un système existant serait fortuite …

              • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                Posté par  (site web personnel) . Évalué à -2.

                Sincèrement, c'est quoi le soucis avec "Program Files" ?

                Avant qu'on me réponde : "ça duplique les fichiers (ex: les dlls)" :

                • on a de la dedup au niveau du système de fichier
                • on a la possibilité de créer des liens symboliques vers d'autres dossiers (c'est d'ailleurs ce que fait Gobolinux)

                C'est facile de voir ce qui est installé avec un simple "ls".

                https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

                • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                  Posté par  (site web personnel) . Évalué à 2.

                  Avis perso : on s'éloigne vachement du KISS avec ce genre de trucs (espace dans le chemin, pas mal d'applis qui peuvent -ou pas- le gérer correctement, accès au dossier dépendant de la locale …), pour un gain pas particulièrement perceptible (pour rester pudique).

                  • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 24 août 2021 à 02:41.

                    Allez, je vais faire l'avocat du diable.

                    on s'éloigne vachement du KISS

                    Quoi de plus simple que de "tar xf appli.tgz -C /programs/appli" ?

                    Pourquoi un gestionnaire de paquet ne pourrait pas installer les dépendances dans /programs et /libraries et gérer les liens symboliques si nécessaire ?

                    En quoi c'est moins KISS que ce qui est fait aujourd'hui:

                    • /usr/bin ou /usr/local/bin ou /bin
                    • /usr/lib(64) ou /usr/local/lib ou /lib
                    • /etc/appli
                    • /usr/shared/appli

                    Aujourd'hui une appli est éclatée partout sur le système de fichier, et à moins d'avoir le gestionnaire de paquet pour:

                    • te lister les fichiers installés par un paquet
                    • te dire a quel paquet appartient tel fichier

                    Ben c'est pas "KISS" selon moi, alors que tout dans /programs/appli, ça l'est.

                    espace dans le chemin

                    Je parlais du concept derrière, pas du détail d'implem. Dans "/programs" il n'y a pas d'espaces.

                    pas mal d'applis qui peuvent -ou pas- le gérer correctement

                    Une appli n'est pas censée être dépendante de la où elle est installée. La preuve la majeure partie des softs sous linux peuvent être installé dans /bin, /usr/bin, /usr/local/bin, /home/user/.local/bin, /opt/appli/bin, etc…

                    Donc /programs/appli/bin ça change quoi ?

                    accès au dossier dépendant de la locale

                    Sous Windows, c'est l'explorateur qui fait la traduction. Il me semble que la plupart des bureaux GNOME te créent aussi des dossiers dans ton $HOME : Documents, Musics, Videos, etc… dépendant de la locale.

                    Si ls et cd gèrent que /programmes ca veut dire /programs, au niveau du FS j'ai toujours qu'un seul dossier.
                    Ou alors, si c'est pas possible, j'ai des liens symboliques (cc Gobolinux).

                    pour un gain pas particulièrement perceptible (pour rester pudique)

                    Windows a su se passer d'un gestionnaire de paquet depuis les 30 dernières années. Il est extrêmement simple de packager pour Windows. Et même la sauvegarde se résume à un simple copier/coller (pour peu que l'application n'utilise pas le registre windows).

                    D'ailleurs, la retro compatibilité de windows est phénoménale. Je peux installer MS-DOS et upgrade jusqu'à Windows 10 sans soucis.

                    Je peux travailler avec un installeur standalone, le Marketplace Microsoft, chocolatey, ou simplement copier coller les fichiers dans program files, rien ne se marche dans les pattes.

                    Essaye d'utiliser 2 gestionnaires de paquets différents sur un même système Linux, et bonjour les emmerdes.

                    Il est ou le KISS sous Linux ?

                    Et si tu es développeur, c'est encore pire. Je ne fais plus confiance à APT pour installer mes dépendances, heureusement en python il y a poetry/conda, en Go il y a go mod, en rust il y a cargo, en JS il y a npm/yarn, en Elixir il y a mix et avec Docker il y a ton registry favoris.

                    Je n'installe même plus mes interpréteurs/compilateurs via le gestionnaire de paquet. J'utilise :

                    • install manuelle de python/elixir/go
                    • nvm pour node
                    • rustup pour rust

                    Docker n'est pas dans les dépôts officiels, mais ils fournissent le leur.

                    Au final, que je travaille sous Windows, dans un WSL, sur un Linux baremetal, mon workflow restera le même, car sous Linux je finis avec plus de choses dans /opt que dans le gestionnaire de paquet.

                    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

                    • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                      Posté par  . Évalué à 1.

                      Totalement d'accord !

                      Linux c'est le bordel comparé à Windows.

                    • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                      Posté par  (Mastodon) . Évalué à 7.

                      Il n'y a rien qui t'empêche d'installer tout ce que tu veux dans /opt/ si ça te change. C'est d'ailleurs de cette manière que bon nombre d'applis proprios sont installées sous linux.

                      S'il y a une séparation des répertoires, c'est qu'il y a une raison. On sépare binaires, librairies, config et données volatiles. Je ne vois pas en quoi c'est le bordel, au contraire c'est bien rangé.

                      • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                        Posté par  (site web personnel) . Évalué à 2.

                        Qu'il y ait une raison, soit. Il y a toujours une raison pour faire les choses d'une certaine façon. Mais dire que cette façon de faire est plus KISS que le reste, c'est juste faux.

                        • le dossier /bin, /usr/bin et /usr/local/bin permet d'avoir une gestion du PATH plus simple
                        • le dossier /lib, /usr/lib, et /usr/local/lib permet de mutualiser les libs
                        • le dossier /etc permet de centraliser la configuration admin

                        C'est une vision orientée système, et non orientée application. Franchement, regardez Gobolinux pour voir ce qu'il est possible de faire tout en restant compatible.

                        Chacune de ces visions répond à des besoins différents, et il s'avère que dans le second cas, on peut se passer d'un gestionnaire de paquet, et se la jouer à la Slackware (la seule distribution linux vraiment KISS).

                        Je ne vois pas en quoi c'est le bordel, au contraire c'est bien rangé.

                        Peut-être, mais quid de mon argument qui expose la nécessité d'avoir un gestionnaire de paquet pour savoir qui a installé quoi ?

                        Il n'y a rien qui t'empêche d'installer tout ce que tu veux dans /opt/ si ça te change.

                        Si tu m'as lu entièrement, c'est ce que je fais la plupart du temps.

                        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

                        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                          Posté par  . Évalué à 9.

                          C'est une vision orientée système, et non orientée application.

                          En même temps, c’est justement l’intérêt d’un OS de proposer une organisation à une échelle plus large que l‘application, parce-que si tu veux des applis les plus autonomes possibles qui font ce qu’elles veulent et que tu peux mettre où tu veux, tu vas finir par trouver que DOS est l’OS qui te convient le mieux.

                        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                          Posté par  . Évalué à 5.

                          Peut-être, mais quid de mon argument qui expose la nécessité d'avoir un gestionnaire de paquet pour savoir qui a installé quoi ?

                          Je ne vois pas en quoi avoir tout dans le même répertoire te permet de savoir qui a installé quoi. Ni même si c'est installé tout court (installer, ça veut souvent dire plus que copier des fichiers, ça veut dire enregistrer des raccourcis pour qu'on puisse trouver l'exécutable rapidement, peut-être une configuration par défaut (dans le registre ?), des services à démarrer…).

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                            Posté par  (site web personnel) . Évalué à -1.

                            Mauvaise fois.

                            • ls /programs/firefox (ou /nix/store/firefox-somehash, ou …)

                            Dans mon cerveau ça fait tilt que tout ce qui est listé a été installé par firefox.

                            • ls /bin

                            Dans mon cerveau ça fait pas tilt a qui appartient les 1400 binaires qu'on y trouve.

                            Et j'explore plus souvent mon système à coup de cd et ls qu'avec un package manager.

                            installer, ça veut souvent dire plus que copier des fichiers

                            Oui, mais rien n'empêche le reste de l'OS d'aller chercher ces informations dans le dossier de l'application.

                            https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

                            • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                              Posté par  . Évalué à 5.

                              Dans mon cerveau ça fait tilt que tout ce qui est listé a été installé par firefox.

                              Pas de bol, ça a été installé par wapt.

                              Oui, mais rien n'empêche le reste de l'OS d'aller chercher ces informations dans le dossier de l'application.

                              Comment il sait ce qu'il faut chercher dans ce dossier ? Il y a 5 exécutables mais un seul est à lancer l'utilisateur. Quel fichier de conf il faut utiliser par défaut ?

                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                  Posté par  . Évalué à 7.

                  on a de la dedup au niveau du système de fichier

                  Pas vraiment. On a de la déduplication active en option sur zfs et probablement sur btrfs. C'est très consommateur en ressource, sinon il y a de la copie en écriture, mais il faut produire les copies, les une à partir des autres (avec cp --reflink par exemple). Ce n'est pas comme ça que fonctionne les gestionnaires de paquets.

                  C'est facile de voir ce qui est installé avec un simple "ls".

                  Quel est l'intérêt par rapport à la commande de ton gestionnaire de paquet ? (qui va pouvoir en plus t'indiquer la version, une description, etc)

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

                  Posté par  . Évalué à 6.

                  Vu ce que tu décris, j’ai l‘impression qu’un ls dans /gnu/store/ répondra encore mieux à ton besoin que dir dans C:\Program Files. Et ça règle le problème de la duplication des bibliothèques. Personnellement, j‘aime bien trouver toute la documentation dans /usr/share/doc et toutes les configurations dans /etc/ mais quitte à changer ces habitudes pour pouvoir lister les logiciels comme des dossiers, la solution de Guix et Nix est autrement plus élégante que le fourre-tout des Program Files. Et tu n’as pas besoin de changer d‘OS pour en profiter.

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  . Évalué à 10.

          Si déjà tous les logiciels respectaient les specs freedesktop XDG machin pour nettoyer un peu le /home ça serait un grand pas.

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 19 août 2021 à 20:16.

          User (or Unix) Shared Ressources contient des des éléments partagés par les programmes (bibliothèques logiciels surtout), ainsi que divers éléments mis à disposition de tous les usagers (cas des docs)
          Les programmes, au sens de binaires à lancer, sont dans /bin/ ou /sbin/
          Du moins, c'était la philosophie unixienne (FHS) et /usr/ ne devrait rien contenir qui ne soit pas utilisable quand cette partition est montée en réseau ou en lecture seule par exemple. En tout cas le nommage /Programs ne serait que confusant…

          Editable Text Configurations c'est certes des configurations (au format textuel…) mais plus précisément des configuration globales (ou systèmes comme diraient certaines personnes) mais aussi les paramètres par défaut des applications.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

            Posté par  (site web personnel) . Évalué à 10.

            Ça fait des années que certaines configurations globales sont déployées sous /usr. Quelques exemples :

            • /usr/share/fontconfig/conf.avail/10-autohint.conf
            • /usr/share/X11/xorg.conf.d/40-libinput.conf
            • /usr/share/X11/xorg.conf.d/70-wacom.conf

            Et il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous /etc en tant qu'admin local.

            C'est exactement la même chose avec les configurations systemd et udev, les règles par défaut sont catapultées sous (/usr)/lib/{systemd,udev} et les admins locaux peuvent adapter sous /etc.

            Pour l'aspect « textuel » d'/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme /etc/ld.so.cache ou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)

            Debian Consultant @ DEBAMAX

            • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Pour l'aspect textuel, je n'ai pas souvenir d'avoir vu du binaire dans /etc jusqu'à une époque récente, et même là on avait le fichier compilé à côté du fichier source textuel (cas de pureftp pour son fichier de comptes local par exemple) ; et encore le binaire pouvait être ailleurs (quelque part dans /var normalement, et il me semble l'avoir déjà vu pour postfix sauf erreur.) Quand aux clés ce sont bien des fichiers textuels héhé.

              Dans les exemples que tu prends (fontconfig/conf.avail et X11/xorg.conf.d), ce sont justement des ressources mutualisées (et mis dans /usr/share comme par hasard, et dans une Debian ils sont souvent posés par des paquets -common et similaires) ou partagées par les programmes (d'où /usr/lib comme par hasard)

              Ceci dit mon propos était de signaler que /usr n'est pas synonyme de /Programs Même si les distributions Linux veulent maintenant tout foutre dedans… sujet initial du fil. D'ailleurs quand tu mentionnes du systemd et du udev il ne faut pas oublier que c'est linuxien et sans volonté de respect des conventions…)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  (site web personnel) . Évalué à 9.

          Non au majuscule par pitié !

          Les chemins courts sont une forces d'UNIX. Marre des dossiers à nom à rallonge ;-)

        • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

          Posté par  . Évalué à 1.

          /Applications pour les applis, /Library/Application Support pour la config (ou la variante ~/ pour la config utilisateur).
          Par dessus ça, tu peux mettre la config de launchd^W^W systemd dans /Library/LaunchDaemon (ou la variante ~/ pour la config utilisateur).

          Rajoute un kernel mach, et ça finira enfin par ressembler à un vrai unix.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)

      Posté par  (site web personnel) . Évalué à 1.

      Waouw, merci de l'information, j'avais oublié ce changement sur mon desktop.
      Je suis hyper étonné qu'ils n'aient toujours pas fait ca, Archlinux a fait ce merge au moment où c'était devenu la norme en 2013, il y a donc 8 ans, et ca fera donc 10 ans quand ils sortiront Debian 12 :o

      https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html

      C'est même du coup 3 ans avant que systemd arrive sur Archlinux :p

      Veepee & UNIX-Experience

  • # Surprise, retour à eth0

    Posté par  . Évalué à 8.

    Pour info, petite surprise ici lors du passage de 10 à 11.
    Retour au nommage des interfaces réseau non persistent enp3s0 -> eth0. Ca fait mal au premier reboot quand ssh ne répond plus.

    Apres branchement clavier et écran, et en créant le fichier /etc/systemd/network/99-default.link, c'est revenu à la normale.

    C'est sans doute du à l'historique de ces 2 machines qui ont bien vécues: installation initiale en Lenny, survécu au passage de systemd…
    Je crois qu'il faudra prévoir une réinstall from scratch pour la version 12.

    • [^] # Re: Surprise, retour à eth0

      Posté par  . Évalué à 5.

      Juste pour être sûr de bien comprendre, ce changement est intervenu sur tes machines ("dû à l'historique") mais on a pas à s'attendre à la même blague pour toutes ? Tu as une idée de ce qui a provoqué ça chez toi ?

      • [^] # Re: Surprise, retour à eth0

        Posté par  . Évalué à 5.

        Sur ces 2 ebox B202 avec ce soucis, c'est du i386, qui est tjs supporté par Debian, mais sans doute moins testé. Plus l'historique de monté de version qui doit pas aider.
        Difficile de diagnostiquer plus avant sur des historiques aussi anciens, mais il faut peut etre être prudent avant de faire ces majs à distance sur des configs aussi chargées.

        Sur 2 autres machines x64 "moins" fossilisées ( seulement 8->9->10->11), c'est passé sans ce désagrément.

        • [^] # Re: Surprise, retour à eth0

          Posté par  (site web personnel) . Évalué à 7.

          Vu d'ici, la différence i386 vs. amd64 devrait être absolument sans rapport.

          Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle udev ou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas de net.ifnames qui traîne…

          En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un 70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?

          Il y a peut-être la réponse dans tes logs. :)

          Debian Consultant @ DEBAMAX

          • [^] # Re: Surprise, retour à eth0

            Posté par  . Évalué à 1. Dernière modification le 20 août 2021 à 20:18.

            Oui, j'avais aussi pensé à une régle udev mais pourtant:

            $ls -Rl /etc/udev/
            /etc/udev/:
            total 12
            drwxr-xr-x 2 root root 4096 17 avril  2015 hwdb.d
            drwxr-xr-x 2 root root 4096  7 août   2018 rules.d
            -rw-r--r-- 1 root root  305  2 févr.  2021 udev.conf
            
            /etc/udev/hwdb.d:
            total 0
            
            /etc/udev/rules.d:
            total 0

            Et notamment pas le 70-persistent-net.rules que j'avais supprimé lors d'une dernière migration.

            J'ai jeter un oeil à /var/log/apt/term.log mais rien d'évident, à mon niveau en tout cas.
            Si vous avez d'autres idées de log à regarder, je veux bien regarder par curiosité intellectuelle.

            De toute facon entre l'age des machines, et la possible fin de support de i386, pas sur que ca passe à Debian 12.

            • [^] # Re: Surprise, retour à eth0

              Posté par  (site web personnel) . Évalué à 2.

              Je pensais plutôt aux logs du système avant/après la mise à jour, à comparer avant et après correction.

              Je vois typiquement ceci ici (installation Debian 11 standard, pas de migration) dans /var/log/{kern,syslog}* et/ou dmesg (en fonction de l'uptime/du logrotate) :

              Aug 17 14:45:15 tokyo kernel: [    1.640746] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) a0:8c:fd:2a:bd:8a
              Aug 17 14:45:15 tokyo kernel: [    1.640748] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
              Aug 17 14:45:15 tokyo kernel: [    1.640797] e1000e 0000:00:1f.6 eth0: MAC: 12, PHY: 12, PBA No: FFFFFF-0FF
              Aug 17 14:45:15 tokyo kernel: [    1.641487] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0
              

              ou bien (installation Debian 10 standard, pas de migration) :

              Aug 16 15:52:58 hamburg kernel: [    1.558838] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 2c:44:fd:2b:a9:8f
              Aug 16 15:52:58 hamburg kernel: [    1.558839] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
              Aug 16 15:52:58 hamburg kernel: [    1.558869] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 0100FF-0FF
              Aug 16 15:52:58 hamburg kernel: [    1.695614] e1000e 0000:00:19.0 eno1: renamed from eth0
              

              (Ici j'ai cherché le eth0 historique qui se retrouve renommé en autre chose, mais je t'invite à chercher les deux noms dans les logs en question.)

              Debian Consultant @ DEBAMAX

              • [^] # Re: Surprise, retour à eth0

                Posté par  . Évalué à 1.

                Voici ce que j'ai pu trouver.
                Je n'ai pas retrouvé de log de démarrage avant mise à jour.

                Démarrage après upgrade

                Aug 10 13:20:20 ebox systemd-udevd[231]: /etc/systemd/network/99-default.link: No valid settings found in the [Match] section, ignoring file. To match all interfaces, add OriginalName=* in the [Match] section.
                Aug 10 13:20:20 ebox systemd[1]: Started Rule-based Manager for Device Events and Files.
                Aug 10 13:20:20 ebox systemd[1]: Starting Network Service...
                Aug 10 13:20:20 ebox systemd-udevd[236]: Using default interface naming scheme 'v247'.
                Aug 10 13:20:20 ebox systemd-networkd[237]: Enumeration completed
                Aug 10 13:20:20 ebox systemd[1]: Started Network Service.
                Aug 10 13:20:20 ebox systemd[1]: Starting Wait for Network to be Configured...

                puis un peu plus loin

                Aug 10 13:20:20 ebox kernel: [    5.764095] r8169 0000:03:00.0 eth0: RTL8168c/8111c, 00:12:23:34:45:67, XID 3c4, IRQ 27
                Aug 10 13:20:20 ebox kernel: [    5.764108] r8169 0000:03:00.0 eth0: jumbo features [frames: 6122 bytes, tx checksumming: ko]

                Enfin, après rétablissement de /etc/systemd/network/99-default.link

                Aug 21 13:15:40 ebox systemd[1]: Started ifup for enp3s0.
                Aug 21 13:15:40 ebox systemd-networkd[238]: enp3s0: Link UP
                Aug 21 13:15:40 ebox systemd-networkd[238]: enp3s0: Gained carrier
                Aug 21 13:15:40 ebox systemd-networkd[238]: enp3s0: Gained IPv6LL
                Aug 21 13:15:40 ebox sh[574]: enp3s0=enp3s0
                Aug 21 13:15:40 ebox kernel: [    5.855206] r8169 0000:03:00.0 enp3s0: renamed from eth0
                Aug 21 13:15:40 ebox kernel: [   26.146512] r8169 0000:03:00.0 enp3s0: Link is Down
                Aug 21 13:15:40 ebox kernel: [   29.124674] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control off
                Aug 21 13:15:40 ebox kernel: [   29.124701] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
  • # Souci de dispo du nouveau noyaux

    Posté par  . Évalué à 1.

    Perso, la mise à jour (de 10 à 11) cest plutôt bien passé sur un serveur sauf pour ce qui concerne le noyau.

    Il n'a pas été ajouté dans /boot et après pas mal de galère, il a fallut faire un install --reinsintall pour que le nouveau noyau soit ajouté correctement au /boot et donc puisse être utilisé.
    Cette situation semble pas très courante car difficile de trouver des infos (un apt install me disais que tout était correctement installé avec la bonne version).

    • [^] # Re: Souci de dispo du nouveau noyau

      Posté par  (site web personnel) . Évalué à 4.

      Tu aurais les logs de la mise à jour ? Typiquement, sous /var/log/apt/, fichiers term.log*.

      J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer vmlinuz & friends dans /boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg… ENOSPC chemin faisant ?

      Note que les deux commandes apt-get et apt gère la commande reinstall (pour install --reins(in)tall). ;)

      Debian Consultant @ DEBAMAX

      • [^] # Re: Souci de dispo du nouveau noyau

        Posté par  . Évalué à 1.

        Je n'ai rien trouvé de probant dans le fichier term.log. C'est d'autant plus bizarre que j'avais bien les symlink de visible dans / (qui pointais donc vers le bon nom de fichier pour le nouveau noyau mais sans qu'il n'y ai de fichier dans /boot).

        J'ai fait les même étapes sur une autre machine ce weekend, sans problématique de noyau.

        Un apt autoremove et apt autocleanv entre l'étapeapt upgradeetapt full-upgrade` aurait-il pu avoir un impact sur le noyau disponible ? (Je me demande si j'ai pas fait un autoremove avant de refaire un update avant le full-upgrade).

        P.S: j'arrive pas à éditer mon message précédent pour l'erreur de frappe ^

  • # Le retour de Kiwix

    Posté par  (site web personnel) . Évalué à 8.

    Une autre bonne nouvelle pour cette onzième version de Debian : Le retour de Kiwix dans les dépôts (même dans ceux de Buster) !

    Ce retour est bien expliqué dans ce billet.

    Kiwix permet notamment d'avoir tout Wikipédia sur son ordi, hors ligne. Son retour sera donc particulièrement utile pour tous les projets éducatifs.

  • # Évolutions de l'installeur

    Posté par  . Évalué à 6.

    Puisque Cyril Brulebois traîne par ici, peut-on avoir un résumé des travaux effectués sur l'installeur de Debian ?
    Et puis, je le trouve toujours aussi bon et souple, très léger aussi, mais je me demande quelles évolutions futures sont prévues ou juste imaginées. Les contraintes d'autrefois avec les multiples architectures supportées, sont-elles encore importantes (c'est juste une question) ?
    Voilà voilà et merci pour le boulot!

    • [^] # Re: Évolutions de l'installeur

      Posté par  (site web personnel) . Évalué à 10.

      J'envisageais de faire une petite rétrospective “d-i vs. Debian 11” sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list… → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.

      Tu peux jeter un œil aux annonces publiées sur la liste debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.

      Par exemple, pour le cycle de publication de Debian 11 :

      C'est donc le debian-installer de la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.

      C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver…

      Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.

      Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées cdebconf et gtk+2.0 pour plus de détails).

      J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de stable qui utiliseraient le noyau de stable-backports afin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (comme base-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques, debian-cd s'occupe « bien évidemment » de produire les images d'installation pendant que debian-boot s'occupe de produire le système d'installation à intégrer dans lesdites images.

      Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.

      Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire… Nous avons d'ailleurs déjà une alternative à D-I (Calamares).

      Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur debian-devel-announce@ date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures… Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.

      Debian Consultant @ DEBAMAX

      • [^] # Re: Évolutions de l'installeur

        Posté par  . Évalué à 8.

        Ben mon vieux, je n'en espérais pas tant! merci pour toutes ces infos.

        bien qu'imparfait

        De mon point de vue d'utilisateur avancé c'est un des meilleur, essentiellement pour sa polyvalence et sa souplesse et parce qu'il permet de revenir en arrière, de voir où on en est et de voir où on va.

      • [^] # Re: Évolutions de l'installeur

        Posté par  . Évalué à 2.

        Cyril, si tu es encore dans le coin, que dois-je faire pour avoir un retour sur le patch proposé dans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913431 (partman-base: Add support for kiB, MiB, … input) ?

        En tout cas, merci pour le boulot sur l'installer. Je l'utilise et l'apprécie vraiment beaucoup (la plupart du temps en mode texte, assez souvent en mode rescue dès que j'ai un problème sur une machine)

  • # Mon seul regret : freeipa-client

    Posté par  . Évalué à 4.

    Mon seul regret de cette version de Debian c'est l'absence de FreeIPA-client. Toutes mes machines s'authentifient sur 2 serveurs FreeIPA. Je vais devoir attendre que le paquet apparaisse dans les backports avant de faire la mises à jour…

    Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…

    • [^] # Re: Mon seul regret : freeipa-client

      Posté par  . Évalué à 5.

      Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…

      En effet, il faut que le paquet soit déjà dans testing. Ensuite il faut qu’il soit suffisamment utilisé pour qu’un mainteneur considère que ça vaut le coup qu’il prenne de son temps pour maintenir le backport.

      À savoir que si un paquet est déjà dans testing mais sans backport officiel, je suis en train de bricoler un petit outil pour construire des backports à partir des paquets sources dispo via les dépôts Debian : Debian backports builder

      Attention, ce n’est testé que sur quelques unes de mes machines, pas documenté, et avec des valeurs hardcodées comme l’adresse locale de mon instance de apt-cacher-ng. Et cette situation ne changera que si des tickets sont ouverts sur la forge donnée en lien pour le requérir ;)

    • [^] # Re: Mon seul regret : freeipa-client

      Posté par  . Évalué à 5.

      Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…

      Si tu es intéressé par cette migration, je te conseille de compiler le paquet testing sur stable et de vérifier qu'il fonctionne sans problème pour le rapporter au mainteneur pour qu'il fasse le backport.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Mon seul regret : freeipa-client

      Posté par  . Évalué à 1.

      Je suis dans la même situation: j'ai découvert qu'il manquait le paquet freeipa-client après avoir migré une de mes machines. Mais plutôt que de revenir en arrière, j'ai installé manuellement le paquet depuis sid.

      C'est assez laborieux, car il faut aussi installer toutes les dépendances ( les 5 ou 6 paquets qui ont ipa dans leurs noms) et qui ont aussi été retiré bullseye

      Lorsque toutes les dépendances manquantes ont été installées, il suffit de terminer l'installation par apt install --fix-broken

      Et pour l'instant ça a l'air de bien fonctionner.

      • [^] # Re: Mon seul regret : freeipa-client

        Posté par  . Évalué à 1.

        C'est assez laborieux, car il faut aussi installer toutes les dépendances ( les 5 ou 6 paquets qui ont ipa dans leurs noms) et qui ont aussi été retiré bullseye

        Quand c'est comme ça et que j'ai besoin d'un paquet venant de sid ou testing, et qu'il y a plus de 2 ou 3 dépendances, j'intègre sid ou testing dans mon debian.list (normalement, main suffit, pour ne pas avoir à charger la liste complète des paquets), puis un apt-update et une simulation pour voir si ça colle (ne pas oublier de rétablir debian.list en fin de procédure :-))

        Dans ce cas, il semble que je chargerais beaucoup plus de paquets de sid que tu as eu besoin de le faire (peut-être parce que freeIPA n'était pas installé dans ma buster ?), mais, comme mon système reste cohérent, ça ne m'a jamais posé de problème.

        Dans ce cas, la simulation me donne :

        apt-get install -s freeipa-client
        NOTE: This is only a simulation!
        The following NEW packages will be installed:
          augeas-lenses bind9-utils certmonger freeipa-client freeipa-common ieee-data krb5-config krb5-user libaugeas0 libbasicobjects0 libcollection4 libcrack2 libcurl3-nss libdhash1 libgssrpc4 libini-config5 libipa-hbac0 libkadm5clnt-mit12 libkadm5srv-mit12 libkdb5-10 libnss-sss libnss3-tools libpam-pwquality libpam-sss libpath-utils1 libpwquality-common libpwquality1 libref-array1 librpm8 librpmio8 libsasl2-modules libsasl2-modules-gssapi-mit libsss-certmap0 libsss-idmap0 libsss-nss-idmap0 libsss-sudo libxmlrpc-core-c3 nss-plugin-pem oddjob oddjob-mkhomedir python3-augeas python3-cffi python3-cffi-backend python3-cryptography python3-decorator python3-gssapi python3-ipaclient python3-ipalib python3-ldap python3-libipa-hbac python3-netaddr python3-netifaces python3-nss python3-ply python3-pyasn1 python3-pyasn1-modules python3-pycparser python3-qrcode python3-sss python3-usb python3-yubico sssd sssd-ad sssd-ad-common sssd-common sssd-ipa sssd-krb5 sssd-krb5-common sssd-ldap sssd-proxy
        The following packages will be upgraded:
          libgssapi-krb5-2 libkrb5-3 libkrb5support0

  • # Un total de neuf architectures sont gérées=> Et RISC-V????

    Posté par  . Évalué à 1. Dernière modification le 24 août 2021 à 15:45.

    Je l'ai installé en version RISC-V il y a quelque mois, les mises à jour sont toujours présentes. C'est peut-être pas totalement officiellement supporté ?

    ps. je crois que j'ai compris, il n'y a pas d'« ISO » tout prêt, il faut debootstraper, c'est la différence.

  • # bonne cuvée selon Jack Wallen

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    https://www.techrepublic.com/article/debian-11-moving-forward-while-standing-still/
    un article sobre et intéressant à sa manière.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.